Context aware interaction

ABSTRACT

A network-connected server for meeting initiation has software executing on the server from a non-transitory physical medium, the software providing a function allowing a user to schedule a meeting and to configure availability conditions, a function for informing scheduled participants of the scheduled meeting, a function for receiving indications of availability for the scheduled meeting from communication appliances associated with scheduled participants, and a function for connecting the communication appliances to communicate when the configured availability conditions are met.

CROSS-REFERENCE TO RELATED DOCUMENTS

N/A

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention is in the field of telephony communications andpertains more particularly to methods and apparatus for negotiatingmutual dynamic availability between communications devices connected toa network.

2. Discussion of the State of the Art

In the art of telephony communications, much has been accomplished inconnection-establishment technologies using digital shared bandwidth anddigital network channels. Presence-based communications networks havebeen established that enable a subscriber to see if another subscriberis generally busy or available for communication. One example of suchpresence-based communications is the well-known “I Seek You” (ICQ)network. In general presence-based scenarios, a central server handlesgenerally peer-to-peer connections established between communicationsappliances based on available presence if real-time communication isdesired.

In a general sense, all presence-based protocols that allow voice/videocommunications use a presence status channel such as Instant Message ora Chat, or posted availability status (available/away/busy, etc.) todetermine if there is availability for a conversation to occur betweenthe two parties over a network channel.

One problem with known presence protocol functionality is thatconversation context gathering is not formalized. An example of thiswould be that a problem someone is having can be described in a chatsession, but the session is basically free form so the requester is notaware of exactly what the other party needs in order to make the bestdecision about how to handle the problem or with what resources. Anotherproblem with known presence based protocols is that a participant cannoteasily control the mutual availability for a planned or pendingconversation. The basic states are statically available or not presentedto anyone following the presence of a participant. The participantcannot selectively become available for certain conversations but notothers.

Still another problem with typical presence-based solutions is thatthere is no formal model for negotiating availability between two ormore parties. For example, a participant might state in a chat sessionto one who is currently unavailable, “Can we talk in five minutes”? Theperson targeted by the request would be required to notice and read themessage, to understand the request, and then reply to the request bymanually typing a reply. This is not very convenient or efficient in afast-paced communications environment.

Therefore, what is clearly needed is a system for electronic negotiationof mutual availability between two or more parties intending tocommunicate, such that the pending communications session is mostconvenient for all of the parties concerned.

SUMMARY OF THE INVENTION

The problem stated above is that formalization of and better control ofnegotiating for availability of two or more participants to engage in acommunications session is desirable for a communications network, butmany of the conventional means for negotiating availability betweencommunications appliances, such as static indications of currentpresence-based availability status presented over an instant messagechannel are not flexible and leave fewer opportunities for userconvenience or satisfaction. The inventors therefore consideredfunctional components of a server-brokered communications network,looking for elements that exhibit interoperability that could beharnessed to provide availability negotiation between communicationsappliances, but in a manner that is most convenient for all parties tothe pending communication.

Every successful communications network is marked by good quality ofservice and convenience of use, one by-product of which is an abundanceof content consumers who may rely on that network for a variety ofcommunications purposes including ecommerce. Most such communicationsnetworks employ servers and executable software to conduct the businessof determining when a connection may be established and building theconnection quickly and efficiently, and servers running softwareapplications are typically a part of such apparatus.

The present inventor realized in an inventive moment that if, at thepoint of intent to communicate, availability of the other party relativeto the availability of the requester could be better controlled,significant reduction in waste relative to communicating over a networkmight result. The inventor therefore constructed a unique system fornegotiating mutual availability for two or more parties having intent tocommunicate, but constrained the parties to mutual availability within aspecified time window. A significant improvement in control overavailability negotiation between two or more communications appliancesresults, with no impediment to quality of service or ease of usecreated.

Accordingly, in an embodiment of the present invention, anetwork-connected server for meeting initiation is provided, comprisingsoftware executing on the server from a non-transitory physical medium,the software providing: a function allowing a user to schedule a meetingand to configure availability conditions, a function for informingscheduled participants of the scheduled meeting, a function forreceiving indications of availability for the scheduled meeting fromcommunication appliances associated with scheduled participants, and afunction for connecting the communication appliances to communicate whenthe configured availability conditions are met.

In one embodiment a part of the configuration of a scheduled meeting isa threshold of number of scheduled participants being available toparticipate. Also in one embodiment there is a function for informingscheduled participants of availability of other scheduled participants.Further in one embodiment one communications appliance is a mobiletelephone and another communications appliance is an interactive voiceresponse (IVR) unit. In another embodiment one communications applianceis a personal computer and another communications appliance is a webserver.

In one embodiment there is a function using geo-location ofcommunications appliances relative to geo-location of an applianceassociated with the user who schedules the meeting to prioritize a listof contacts on the user's appliance. Also in one embodiment, in additionto receiving indications of availability the server receives indicationof applications running on the communications appliances associated withscheduled participants. Availability may be accomplished through a pingsequence or a text channel. In some cases certain expected geo-locationpositions and states of a party's mobile communications appliance areconfigured as conditions for availability of the party.

In another aspect of the invention a method for meeting planning andinitiation is provided, comprising the steps of (a) scheduling ameeting, including participants, and configuring availability conditionsfor participants required to initiate the meeting at a network-connectedserver; (b) informing scheduled participants of the scheduled meeting bythe server; (c) receiving indications of availability for the scheduledmeeting from communication appliances associated with scheduledparticipants; and (d) connecting the communication appliances tocommunicate when the configured availability conditions are met.

In one embodiment, in step (a) a part of the configuration of ascheduled meeting is a threshold of number of scheduled participantsbeing available to participate. Also in one embodiment, in step (b)scheduled participants are informed of availability of other scheduledparticipants. Still in one embodiment one communications appliance is amobile telephone and another communications appliance is an interactivevoice response (IVR) unit, and in another embodiment one communicationsappliance is a personal computer and another communications appliance isa web server.

In some embodiments there is further a step for using geo-location ofcommunications appliances relative to geo-location of an applianceassociated with the user who schedules the meeting to prioritize a listof contacts on the user's appliance. Also in some embodiments, inaddition to receiving indications of availability the server receivesindication of applications running on the communications appliancesassociated with scheduled participants. Availability reporting may beaccomplished through a ping sequence or a text channel. Further, statesof a party's mobile communications appliance may be configured asconditions for availability of the party.

BRIEF DESCRIPTION OF THE DRAWING FIGURES

FIG. 1 is an architectural diagram of a communications network thatsupports dynamic availability negotiation between two or morecommunications devices.

FIG. 2 is a process flow chart illustrating steps for reportingavailability of call center agents according to an embodiment of thepresent invention.

FIG. 3 is an architectural diagram of a communications networksupporting dynamic availability negotiation according to an embodimentof the present invention.

FIG. 4 is an interaction chart illustrating a process for brokeringcommunication between two communications appliances according to anembodiment of the present invention.

FIG. 5 is a block diagram illustrating call center invitation ofpotential customers including availability negotiation according toanother embodiment of the present invention.

DETAILED DESCRIPTION

The inventors provide a system described below in several embodiments asa Meeting Arrangement Service (MAS) for dynamically negotiating mutualavailability for two or more parties having intent to communicate, thecommunication to occur between two or more communications appliancesover a network. The process enables dynamic availability coordination sothat the time of the communication is suitable and hopefully best forall communicating parties. The present invention is described inenabling detail using the following examples, which may describe morethan one embodiment falling within the scope of the present invention.

FIG. 1 is an architectural diagram of a communications network 100 thatsupports a MAS providing availability negotiation between two or morecommunications devices according to an embodiment of the presentinvention. Communications network 100 in this example includes a callcenter supported by a local area network (LAN) 101. The call centercomprises various pieces of equipment hosting software that aresupported by LAN 101. LAN 101 supports a central telephony switch 102.Telephone switch 102 may be a private branch exchange (PBX) or othersuitable hardware telephone switch. In one embodiment, telephone switch102 is a switch implemented in software on a computing appliance.

Telephone switch 102 is enhanced for computer telephony integration(CTI) by a CTI processor 104 connected to LAN 101 and to telephoneswitch 102 via a CTI link. CTI processor 104 provides intelligentrouting instruction and call processing control to switch 102. Switch102 has connection to an interactive voice response (IVR) unit 103.Callers may access telephone switch 102 through any telephony carriernetwork, including digital carrier networks. Callers may also accessswitch 102 from the Internet network without departing from the spiritand scope of the present invention.

In this example, persons operating mobile communications appliances112(1−n) may access call-center telephone switch 102 via a wirelesscarrier network 110, and a wireless media gateway 116 having connectionto LAN 101. In actual practice and other embodiments, persons may accessswitch 102 through a telephony network such as the public switchedtelephone network (PSTN) not illustrated in this example to save space.Wireless network 110 represents any digital wireless telephony carriernetwork and access to both PSTN resources as well as data networkresources such as Internet access.

LAN 101 in the call-center supports a statistics server 105. Statisticsserver 105 includes a non-transitory digital medium that contains all ofthe software and data required to function as a statistics server for acall center. Statistics server 105 can serve information that is typicalof call center operation data such as estimated waiting time (EWT) inqueue, average call handling time, and like statistics. LAN 101 alsoincludes an outbound dialing server 106. Outbound dialing server 106includes a non-transitory physical medium hosting all of the data andsoftware to enable outbound dialing through telephony switch 102.

LAN 101 supports an interaction server 111. Interaction server 111includes a non-transitory physical medium that hosts all of the data andsoftware to enable function as an interaction server. Interaction server111 is adapted to queue and serve interactions to individual ones ofagents 113 (1−n) working in an agent group. In this example interactionsmeans telephony events, but in other embodiments may mean any voicebased or text based communication functionality. In this example eachcall center agent may be stationed at an agent workstation (eachrepresented herein by a personal computer icon) including a personalcomputer and a PBX or other type of telephone or telephony applicationfor enabling voice and possible video/voice communications, and in otherembodiments text-based communication as well.

In typical call center interaction scenarios, potential customers callinto the site from external networks using, in this example, mobilecommunications appliances, and are routed through the network totelephone switch 102 in the call center. An IVR 103 may respond to callsarriving at switch 102 and determines the intent of the call and theidentification of the caller. Identification may also be ascertained bycall data. Based on this information, a routing routine is typicallyused to place the call in an appropriate queue for later connection toan agent in the event that no live assistance is currently available.Callers may be informed by IVR 103 an approximate wait time for anagent. Callers may typically be on hold perhaps listening to music untiltheir call is finally routed to a live agent.

In this example, an availability monitoring server 108 is provided.Availability monitoring server 108 includes a non-transitory physicalmedium containing all of the data and software required to enablefunction as a server capable of serving availability information. Inthis example, server 108 keeps track of activity of interaction server111 and determines current availability status relative to agent group113 (1−n) with the aid of an availability messaging application (AM/SW)109. In general, there are two states of availability for aconversation, ready and not ready. These are typical presence-basedstates; however, agents may also have a predicted state of readiness insome embodiments. That is to say that for a particular agent, readinessto have a conversation may be predicted by taking into account averagehandling time and number of interactions in queue.

Application 109 is capable of sending availability messages to potentialcustomers like operators of communications appliances 112 (1−n). In thisexample each communications appliance 112 (1−n) has a client SWapplication 114. SW 114 includes capability of receiving and sending AMstate messages. SW 114 is also able to initiate a connectionautomatically with another communications appliance or system adaptedwith SW to participate. In one embodiment the communication sessions areaccomplished using session initiation protocol (SIP). The presentinvention can be practiced in various call center embodiments whetherthey are inbound or outbound with proactive contact.

In one embodiment a communications appliance like one of 112 (1−n) isused to make initial contact with the call center. When the call reachesswitch 102 IVR 103 intercepts the call to determine caller intent androuting. The caller may, instead of waiting to be routed to an availableagent, be queued in a virtual queue. The caller may hang up but remainavailable to the network meaning the communications appliance isswitched on and accessible over the network. The caller may havepreferred periods of availability based on a personal schedule. Thecaller may also have preferred periods of availability tied in togeo-location and schedule. These configurations of availability in thisexample are a part of data available to SW 114 executing on thecommunications appliance. The constant desired status for agentavailability in this example is “ready” for a conversation. However, dueto incoming call load, none of the agents may be available at certainpeak periods.

Availability monitor SW 109 running on server 108 may send availabilitymessages to certain callers when one of agents 113 (1−n) is ready for aconversation. A communications appliance that receives a “ready” messagemay with appropriate indication to the caller, initiate a connectiondirectly to the agent that is reported to be ready for a conversation.The caller may also elect to send availability messages to the callcenter periodically. Server 108 running availability monitor software109 may take into account that certain callers have availabilitypreferences tied to schedule or to geo-location. When a communicationsappliance sends a “ready” message, the call center may attempt to callthe appliance if an agent is also ready for a conversation at that time.The call center makes an attempt to connect only when both conversationparties are “ready” to have a conversation. Availability monitoringserver 108 may subscribe to statistics server 105 to receive statisticsthat may help to predict future readiness of an agent to have aconversation.

In a preferred embodiment, there are two modes, manual and automatic,for initiating a connection (conversation) between two or morecommunications appliances like 112 (1−n). In manual mode, the callerreceives an availability monitor message of “ready” for a conversation.Ready for conversation implies that there is no wait time in queue andthat the caller will be connected to an agent if the pending connectionis manually accepted. The caller manually accepts the pending connectionby pressing a designated button or adapted touch screen icon associatedas an input with SW 114. The caller may manually select an option toconnect, which will initiate a call either directly to the ready agent,or in such manner that the queue may be bypassed so the caller isimmediately connected. IVR 103 may be adapted to recognize suchconnection attempts that follow a ready message so that the caller isunderstood to have a “reservation” for a ready agent as a result of thecaller action of “accepting” a ready message.

In automatic mode, the communications appliance may receive a “readymessage” and may automatically initiate a connection with an appropriatealert so the caller should know what the appliance is doing. Anindication 115 of the receipt of a “ready” message may be provided as aflashing icon with an audio tone. The caller may have one or moreavailability constraints tied to personal schedule or geo-location [GPS]feature. For example, if the caller is in automatic mode and currentgeo-location places the caller at a location to which the caller may notconverse using the communications appliance, the auto-connect featuremay be overridden. Manual mode allows the caller to accept or reject apending connection. In virtual queue situation where more than onecaller may be waiting for an agent to be ready, the order of callers inthe virtual queue is taken into account as well as which of thosecallers have reported or otherwise have the state of “not ready”.Therefore, a caller in front of the queue may be passed over for anothercaller if the former is “not ready” and the other caller in the queue is“ready” for the pending connection.

This particular example illustrates a call center embodiment thatincludes a sophisticated virtual queuing system. In another embodiment,the invention may be practiced by more than two parties such as severalparties to a conference bridge, for example. A pending conference callmay be initiated if all parties or a pre-programmed portion of allparties report a readiness to participate in the call. In this case,ready messages may be reported periodically from the participatingappliances and when some threshold is reached in the number of partiesreporting ready, the conference may be initiated automatically, and eachparty invited to the conference may automatically connect to the bridgewith appropriate indication to the caller.

In one embodiment the present invention is practiced in a peer-to-peermode between two communications appliances one or both of whoseoperators desire a conversation when both parties are suitably “ready”to have the conversation. In this case, the parties through theirrespective communications appliances via a version of SW 114 may sendand receive availability messages and negotiate connection to occur at amutually beneficial time. In general, when both parties are suitablyavailable, the connection may be automatically or manually initiatedfrom either side.

FIG. 2 is a process flow chart 200 illustrating steps for reportingavailability of call center agents according to a variation of theembodiment of FIG. 1. It is assumed in this example that the user is aparticipant in the present invention and has an instance of SW 114running on the communications appliance used to initiate the pendingconversation.

At step 201 the user calls a contact center adapted to practice theinvention. At step 202, an IVR system intercepts the call and interactswith the caller. At step 203 the IVR obtains the context of the call andcaller intent. In one embodiment, the invention is practiced when thecaller requires live assistance and there are currently no availableagents on hand at the time of the call. As a part of agent levelrouting, the system checks agent availability for call routing at step204. At step 205 the system determines if there is a ready agent to takethe call. If an agent is readily available at step 205, then the calleris routed to the available agent at step 206. The process ends for thatcaller at step 207 because there was an agent available to take thecall.

If it is determined that there is no available agent at step 205, thenat step 208 the availability monitor may aggregate availability data.The IVR may prompt the caller to set up for availability reporting atstep 209. Availability monitoring may be practiced by the call center ingeneral on behalf of any agent or group of agents. Here the caller hastwo choices available. At step 210 the caller may decide to set dynamicmode or automatic mode. If the caller decides to use dynamic mode atstep 210, the communications appliance used by the caller uploads anyavailability preferences to an availability monitoring server at step211. An availability preference may be tied to current caller scheduleor to a geo-location [GPS] state, or both.

After the user uploads availability preferences at step 211, the usermay then disconnect from the call center telephone number. This step isnot illustrated but may be assumed. Likewise, the user is placed in avirtual queue so that queue position may be a factor in availabilityreporting. The queue may have a certain time-out period if mutualavailability negotiation between the user and the call center does notresult in initiation of a conversation within a certain period of time.The availability messaging component of the monitor application sendsperiodic availability messages to the communications appliance of theuser. In the event that no agent is available at step 212, the messagesent to the user reads “not ready” and the process loops back to thereporting step.

Periodic reporting may occur every few minutes or less frequently ifwarranted such as at high peak periods with high estimated waiting time.Availability reporting may also be subject to availability preferencesof the user uploaded at step 212. For example, if the user has a “notavailable setting” tied to one or more geo-locations [GPS states], thecommunications appliance may report or send an availability message of“not ready” whenever the GPS state exists on the mobile phone. In thisexample, the user is not sending availability messages to theavailability monitoring server, but may be set to send availabilitymessages if so desired. Availability preferences may also includeexplicit statements such as “I am not available between time A and timeB”.

At step 212, if the system determines availability of a suitable agentfor handling the call, the availability monitoring sever, using amessaging component, sends an availability message of “ready forconversation” or something to that effect to the user's communicationsappliance. In dynamic mode, as soon as the appliance receives themessage, it may automatically initiate a connection to the call center,more specifically, to the available agent at step 213. It is notedherein that this is not an outbound scenario as the call center is notcalling the user back. Rather, the user is automatically retrying theoriginal call when mutual availability is successfully negotiated.Therefore, after receiving an availability message of “ready”, theuser's communications appliance begins initiating the connection withthe appropriate notification to the user.

In one embodiment, a flag or cookie system may be in place to enable thecall center system to recognize that the new call is the result of asent message of readiness to converse on behalf of an available agent.The user may still be in virtual queue at the time of the connectattempt of step 213. An audible sound along with a visual indication mayoccur on the communications appliance while the attempt is made so theuser may notice this and participate in the call. In one embodiment, anavailability monitoring message of “ready” may include a direct numberto dial or a link to activate during the automated connection attempt.

At step 210, the user may decide not to set connection initializationsettings to dynamic or auto-mode. The process then moves to step 214 andthe user may determine to set the initialization settings to manualmode. If the user determines not to set availability reporting to manualmode at step 214, then the process may resolve back to step 209 implyingthat the user should employ one of the two modes to be successfullyconnected when a ready message is received at the communicationsappliance operated by the user.

If the user determines to set initialization settings to manual mode atstep 214, the user may then disconnect from the call center and rely onavailability messages received from the call center to be notified of anagent who is ready to have a conversation. In this case, the user willdecide manually whether or not to initiate contact with a “ready” agent.The availability monitor may push messages to the user regardingavailability of the agent. If there is an agent available at step 215,the server sends a message to the communications appliance that an agentis “ready” to converse at step 216. If at a reporting interval, an agentis not available, then the server sends a “not ready” message at step217. In the case that the user receives a “ready” message, the user maymanually decide to initiate a connection with the ready agent.

In one embodiment, a flag or cookie system may be in place to enable thecall center system to recognize that the new call is the result of asent message of readiness to converse on behalf of an available agent.The user may be placed in virtual queue at the time of the original calland may still have a place in queue at the time of a manual connectionattempt as a result of a “ready message”. A timeout may be imposed inthe queue to prevent the system from representing users who areunavailable or have repeatedly refused to connect in manual mode uponreceiving a ready message.

FIG. 3 is an architectural diagram of a communications network 300supporting availability negotiation according to another embodiment ofthe invention. Communications network 300 includes an Internet network301. Internet network 301 supports a Web server 306. Web server 306includes a non-transitory physical medium that contains all of thesoftware and data required to enable server function as a Web server.Web server 306 hosts a Web page 309. Web page 309 may be a site whereusers may register with an availability negotiation service and whereinthose users may download client application 114.

An availability monitor server 304 is provided and supported in Internetnetwork 301. Server 304 includes a non-transitory physical medium thatcontains all of the software and data required to operate as anavailability monitoring message server. Availability monitoring software109 includes a capability of monitoring availability status ofcommunications appliances registered with the service. A mass repository305 is provided and is adapted to contain current availability status ofregistered appliances that are connected to the network.

Communications network 300 includes a wireless carrier network 302 and awireless carrier network 303. Networks 302 and 303 may be segments of asame carrier network, or they may be separate carrier networks. Acommunications appliance 307 is illustrated in this example and has aninstance of SW 114 executing thereon. Communications appliance 307 maybe a cellular telephone, a smart phone, an iPad, a laptop, or some othercommunications appliance capable of a mobile wireless connection. In oneembodiment, the invention may also be practiced to some extent usingland-line connected communications appliances. In this example,communications appliance 307 connects to Internet 301 through a mediagateway 310.

A communications appliance 308 is illustrated in network 303 and is alsoexecuting client software 114. Communications appliance 308 connects toInternet 301 through media gateway 311. It will be appreciated thatdifferent modes of Internet connection may be practiced withoutdeparting from the spirit and scope of the present invention. In thisexample, the users operating appliances 307 and 308 have an “intent” tohave a conversation with one another using the registered appliances. SW114 includes an availability reporting component and an availabilityrequesting component. Communications appliances 307 and 308 areconnected to server 304 when sending and receiving availabilitymessages. Availability status reporting and availability negotiation isbrokered by server 304 on behalf of the users operating the appliances.

While connected to server 304, appliances 307 and 308 may sendavailability messages to one another. Availability messaging may useinstant messaging, chat, simple message service (SMS), multimediamessage service (MMS), or a real simple syndicate (RSS) feed to conveyavailability information about the other party to each user. In oneembodiment, each communications appliance includes a contact list ofusers that illustrates connectivity state for receiving and sendingavailability messages for each user. A user may then open a contactapplication and see present information such as “connected” or “notconnected” for availability messaging.

Assume now that the user operating appliance 307 from network segment302 wishes to have a conversation with a user operating appliance 308from network segment 303. The user operating appliance 307 whileconnected to server 304 may open a contact application aided by SW 114and see if the other party operating appliance 308 has connection toserver 304. If so, the parties may report availability states to oneanother. In this case, the messaging is brokered through server 304. Themessaging process may consider one or more rules relative to“availability to have a conversation” into account. Rules may involveGPS coordinates such as “not available” if at the following GPSlocation(s), or explicit constraints such as “not available” between12:00 PM and 2:00 PM Monday through Friday. SW 114 may includeintegration with other applications such as navigator applications andcalendars or scheduling applications.

The user operating appliance 307 may connect to server 304 and uploadavailability preferences if any are desired. An availability preferencesimply provides some constraint on initiating a conversation withanother party. Both parties may have availability constraints configuredin an “intent to communicate” scenario. The user operating appliance 307may desire to communicate with the user operating appliance 308 and mayrequest availability reporting from the user operating appliance 308. Asa convenience, the user may also elect to send availability messages tothe other party.

User 307 may set actions related to availability reporting. If desired,the user operating appliance 307 may set a dynamic connection attempt inthe event of the first report indicating that the user operatingappliance 308 is “ready” to have the conversation. In this scenario,appliance 307 periodically receives availability state of appliance 308from server 304. When a “ready” message is received at the firstopportunity, appliance 307 will automatically call appliance 308 unlessthe availability status of appliance 307 is “not ready”. If appliance307 receives a “ready” message from server 304 on behalf of appliance308, but at the time a constraint is in place indicating a not readystatus, the appliance will wait until a next “ready” message is receivedfrom the server. By the same token, availability status messages aresent to appliance 308 from server 304 indicating ready or not ready fora conversation.

Some optimization occurs in server 304 regarding availability messaging.For example, if a constraint exists on appliance 307 for a period oftime, server 304 may decline sending any availability messages toappliance 307 during the lifetime of the current constraint. Likewise,the constraint may be reported in an availability message to appliance308 as “not ready” followed by an indication of an end time for theconstraint. In this way, server 304 can streamline messagingaccordingly. However, in some embodiments manual settings may enable anoverride of a local constraint. For example, if the user operatingappliance 307 has a “not ready” constraint in place, but receives a“ready” message from appliance 308, the user may connect to appliance308 manually overriding the constraint. The user operating appliance 308may have one or more constraints to availability as well. In this way,mutual agreement is forged between the appliances relative to a moreopportune time for both users to communicate.

The present invention is applicable to different call modes likeconference calling, for example. In conference mode, each party mayreport availability including uploaded geo-location, scheduleconstraints, and preferences wherein the conference is initiated by aconference bridge (party always available) when all of or at least acertain number of the parties indicate availability in messaging to thebrokering server, in which case the conference bridge could be enabledto message the “join” instructions and start time to all of the partieshaving an “intent” to communicate.

In one embodiment, a user operating a registered appliance may requestavailability reporting from any contact connected to the server to sendor receive availability messaging. In one embodiment, a contact list ofusers on a registered communications appliance is optimized by GPSproximity such that the contacts are listed in priority order accordingto proximity as indicated by GPS coordinates. In this application,closest contacts are listed first in the contact list. In oneembodiment, these contacts are prioritized according to overallavailability rating over time. In this scenario, a contact that shows an80% overall availability rating might be listed before a contact showing60% overall availability over the same period.

FIG. 4 is an interaction chart 400 illustrating a process for brokeringcommunication between two communications appliances according to anembodiment of the present invention. In the previous example there aretwo communications appliances and the messaging server. Interactionchart 400 provides a description of a possible interaction scenariobetween a communications appliance A, an availability monitoring server,and a communications appliance B.

A user operating appliance A may send a request to the server foravailability reporting for communications appliance B, which isconnected to the server and which is a contact of communicationsappliance A. In this step the user operating appliance A may elect toauto-initiate a connection upon receipt of a ready message from theserver indicative that appliance B is ready for a conversation. Theserver may send a request to get availability from communicationsappliance B. Communications appliance B may upload availabilitymonitoring information to the server. This information may includeschedule dependant, geo-location dependent and explicit availabilityinformation.

The server sends an availability message on behalf of communicationsappliance B to communications appliance A wherein the current state is[Not Ready]. Upon receiving the message that appliance B is not ready,the local software does not initiate a connection and waits.Communications appliance A sends availability status to the server. Theserver then sends a message to communications appliance B thatcommunications appliance A is ready to have a conversation. However, atthe time of receipt of the message, communications appliance B is notready to have a conversation.

The server sends a message to retrieve another availability monitoringupdate from communications appliance B. In response, communicationsappliance B uploads an update to the server. The server then sends amessage to communications appliance A that indicates that communicationsappliance B is ready to have a conversation. Communications appliance Athen initiates a call setup using SIP in this example. In this case, theavailability monitoring server is SIP enabled and completes one call legbetween communications appliance A and the server. The server thenrequests a call setup with communications appliance B and the secondhalf of the call is established. Both appliances are then connected in acommunication session. It is not required that the server broker thecall setup process in order to practice the present invention. In oneembodiment, communications appliance A simply auto-dials the telephonenumber of communications appliance B.

In one embodiment of the present invention, the service brokers thevoice and video communications as well as the availability reportingbetween appliances. In another embodiment the appliance connects over avoice/video channel directly using standard protocols for suchcommunications. In one embodiment a pinging process may be used todetermine availability, however, an availability message may containadded data of importance to the pending conversation.

In a scenario where one party has intent to have a conversation withanother party, the requesting party is charged with initiating theconnection. In one embodiment one party may request and receiveavailability messaging on behalf of another party while that party sendbut does not receive availability information from the first party. Inone embodiment, the context preceding all conversations is known to bothparties before a conversation occurs. In one embodiment, additionalcontextual data is collected from one or more potential parties to aconversation in order to improve service related to that conversation.Context awareness simply indicates that a party knows beforehand whatthe session will be about before initiating a connection.

FIG. 5 is a block diagram 500 illustrating call center invitation ofpotential customers including availability negotiation according toanother embodiment of the present invention. In one example in a contactcenter scenario for proactive contact, customers visiting the Website ofan enterprise are invited to engage in a conversation. In this scenario,knowledge workers or agents may also be invited to take interactionsbased on availability.

A pool of agent prospects 501 serves as an acceptable pool of agentsthat may be individually invited to take an interaction. An agent pacingalgorithm may govern the frequency at which invitations to take aninteraction are sent. Agents who accept invitations to take aninteraction may automatically send availability monitoring status oravailability status to a third-party server. Agents who have acceptedinvitations become agents waiting on an interaction or a pool of pendingagents 503. A pool of ready agents 504 include those agents who haveaccepted invitations and are “ready” to have a conversation. A timeoutmay be imposed on such agents so that if no interactions are forthcomingthey may go back to other duties. Availability for invited agents isalways “ready” to have a conversation unless a time out has occurred orunless they are one of a pool of busy agents 506 that are in the processconversing with potential customers.

As soon as agents engage a potential customer, the system or anavailability monitoring server may send availability updates informingpotential customers that they are “not ready” to have a conversation.The exact architecture depends in part on the queue structure and thenumber of agents that are actually “ready” for a conversation mayfluctuate during peak and wan periods of call center traffic. However,invitation algorithm 502, also known to the inventors as a pacingalgorithm for pacing the frequency of invitations that are sent toagents attempts to invite enough agents to engage customers that callcenter quality goals are still met at heavy traffic periods. Certainprobability factors are considered such as the probable rate of refusalof agents to accept an invitation {depends on rules}. Other factorsinclude the rate of traffic incoming into the call center, averagehandling time per transaction, and other factors.

In this example, potential customers are proactively culled from theWebsite as they are visiting. An invitation frequency algorithm 512 inprovided for pacing the frequency at which invitations are sent toWebsite visitors 511. Like invitations to agents, invitations to Websitevisitors are paced to account for rejected invitations 513. Websitevisitors who accept invitations to engage in a conversation with anagent are considered “ready” to have a conversation in terms ofavailability status. As soon as visitors are engaged with an agent,however, their availability status changes from “ready” to “not ready”because of the current engagements.

In this example, a dialing function is provided for inbound dialing intothe call center on behalf of the Website visitors. In one embodiment, anoutbound dialing server is used to call the potential customers whilethey are at the Website. Completed calls 510 include all of thosevisitors who were immediately routed to available agents. Thosecustomers who are not immediately connected to an agent are virtuallyqueued in a queue 507. The customers in “queue” may disconnect from thecall center IVR system and do not have to “hold” the line waiting for anavailable agent. Abandoned calls 508 include any visitors thatoriginally accepted an invitation, but failed for one reason or anotherto complete a conversation. One reason for an abandoned call may be thata visitor has constraints placed on his or her availability and thoseconstraints are not met within a certain time period allowed before atimeout occurs.

In this scenario pacing helps to provide enough agents to handleworkflow and to provide enough customer traffic to keep agents busy inconversations or transactions. Agents do not have to be invited to taketransactions in order to practice the present invention. Instead, astatic number of agents may be set up as an agent pool or group to workincoming traffic. Availability status is monitored for both agents andWebsite visitors once they have accepted invitations to engage.Consequentially, when all agents are busy, potential customers receive“not ready” availability messaging for the call center. Those potentialcustomers may automatically connect when a “ready” message is received.The invention may be practiced in automatic mode for automaticconnection initiation, or it may be practiced in manual mode from theperspective of the potential customer.

In a call center environment, an availability status message of “ready”sent to a potential customer means that there is at least one agent whois currently “ready” to have a conversation. Automatic connection of thecustomer's communications appliance to the communications appliance usedby the ready agent may be made while the potential customer has droppedoff of the Website and is not on hold or currently waiting for an agent.The potential customer may still be in a “virtual queue” and messagingmay be tailored to take into account queue position as well as otherfactors.

The pacing concept described above is designed to promote efficiency bysending invitations only to a number of Website visitors that can beserviced successfully by the agent pool given all of the factors andvariables. Therefore, when there are no available agents to servicepotential customers from the Website, the algorithm send frequency dropsdramatically but steadies. As more agents are available, the invitationfrequency shifts upward and more Website visitors are recruited. It isnoted herein that availability messages may be pushed to Websitevisitors and an availability status of “ready” may include a method forbypassing the front-end routing system such as ability for thecommunications appliance to dial directly to the “ready” agent bypassingIVR interception and traditional routing regimens. In a preferredembodiment, conversations that are in progress are monitored for qualityand statistical information like all other call center transactions.

In one embodiment, additional metadata or data about an agent may beprovided within a “ready” message sent to a potential customer from anavailability monitoring server. That data may be displayed for thepotential customer to read before the customer connects to the agent.Likewise, the agent may have additional information about a customersent in an availability message to the agent from the availabilitymonitoring server. Negotiation between two communications applianceswith constraints applied involves waiting to connect at such a time whenit is indicated that both parties are “ready” to have a conversation.

For individual parties, there may be a scenario where a party is engagedin multiple conversation scenarios wherein some of those may takepriority over others of those intent scenarios. For example, bothcontacts A, B, and C report ready for a conversation. Contact A may havepriority because it was the first contact to send availability messagingthat has not yet times out. A client application such as SW 114described further above with reference to FIG. 1 may manage prioritieswith respect to incoming AM from multiple contacts.

In one embodiment, SW 114 could also adjust to the user's personalprofile and preferences for both sending automatic AM updates orreacting on other parties' AM updates. This could include incorporationof personal context information such as scheduled appointments orlocation information. For example, there may be a rule stating “notready” when at location “A” because location A is a bank. Or, “notready” if I am at location B between 10 and 11 because I am attending alecture. Or, “not ready” between 8 and 10 in the morning because I amcommuting. Or, “not ready” when I am moving [GPS] because I am driving acar.

In one embodiment of the present invention, a user may set AM reportingfor other parties by sending a special request. The length of timereporting continues depends on configuration settings. In oneembodiment, a user may desire to talk with an individual whenever thatindividual should become available for a conversation. The requestingparty may subscribe to and may receive AM updates indefinitely fromanother party such that whenever the that other party is connected tothe network AM status of “ready” or “not ready” is propagated.

In another embodiment of the present invention, described briefly aboveas incorporating a concept of a threshold number of participants asavailable to start a meeting, ther may be several other features. TheMAS may keep track of expected attendees' actual (dynamically reported)availability (time and potentially also location) and arrange a meeting(either face-to-face or virtual or mixed, potentially also withdynamically selecting the location) with short notice as soon as arepresentative quorum of attendees will be available. When triggeringsuch event within MAS the meeting initiator can configure (mandatory andoptional) settings such as any one of, combination of, or all of:

-   -   list of invitees, including their “communication intention”        contacts and their contacts for “real communication” (the latter        applies to conference calls where not all invitees are attending        face-to-face)    -   start and end time of the time interval during which the meeting        shall be arranged    -   duration of the meeting (obviously shorter than the time        interval)    -   quorum definition    -   confirmation settings (whether or not invitees have to confirm        their attendance once the meeting will be scheduled)    -   meeting type: (a) conference call w/o geo-location; (b)        face-to-face only; (c) mixed    -   success criteria (for example cancellation if insufficient        confirmation level)    -   number of attempts    -   escalation policy (for example relaxing quorum settings        depending on remaining time)    -   preferences (such as preferred meeting times or locations)

The meeting settings can be archived and reused for subsequent meetings.Additional security can be added in order to prevent intruders tosilently join. This could apply to the conference call, but also to the“communication intention” phase. In this case the configuration of themeeting could be simplified by just asking all invitees to establish a“communication intention” context with MAS and to authenticate to MASwith a given meeting id and passcode.

MAS could work in a case of conflicting meetings. A person may haveseveral (two or more) concurrent meetings with different priorities. Hemight be notified by MAS about current status of each of them therebychanging decision making of this participant. The status of a meetingcould contain such characteristics as number of available participants,time till meeting expiration and others.

It will be apparent to one with skill in the art that the availabilitynegotiation system of the invention may be provided using some or all ofthe mentioned features and components without departing from the spiritand scope of the present invention. It will also be apparent to theskilled artisan that the embodiments described above are specificexamples of a single broader invention which may have greater scope thanany of the singular descriptions taught. There may be many alterationsmade in the descriptions without departing from the spirit and scope ofthe present invention.

What is claimed is:
 1. A network-connected server for meetinginitiation, comprising: software executing on the server from anon-transitory physical medium, the software providing; a functionallowing a user to schedule a meeting and to configure availabilityconditions; a function for informing scheduled participants of thescheduled meeting; a function for receiving indications of availabilityfor the scheduled meeting from communication appliances associated withscheduled participants; and a function for connecting the communicationappliances to communicate when the configured availability conditionsare met.
 2. The server of claim 1 wherein a part of the configuration ofa scheduled meeting is a threshold of number of scheduled participantsbeing available to participate.
 3. The server of claim 1, furthercomprising a function for informing scheduled participants ofavailability of other scheduled participants.
 4. The server of claim 1,wherein one communications appliance is a mobile telephone and anothercommunications appliance is an interactive voice response (IVR) unit. 5.The server of claim 1, wherein one communications appliance is apersonal computer and another communications appliance is a web server.6. The server of claim 1, further including a function usinggeo-location of communications appliances relative to geo-location of anappliance associated with the user who schedules the meeting toprioritize a list of contacts on the user's appliance.
 7. The server ofclaim 1, wherein, in addition to receiving indications of availabilitythe server receives indication of applications running on thecommunications appliances associated with scheduled participants.
 8. Theserver of claim 1 wherein availability reporting is accomplished througha ping sequence.
 9. The server of claim 1, wherein availabilityreporting is accomplished through a text channel.
 10. The server ofclaim 1, wherein certain expected geo-location positions and states of aparty's mobile communications appliance are configured as conditions foravailability of the party.
 11. A method for meeting planning andinitiation, comprising the steps of: (a) scheduling a meeting, includingparticipants, and configuring availability conditions for participantsrequired to initiate the meeting at a network-connected server; (b)informing scheduled participants of the scheduled meeting by the server;(c) receiving indications of availability for the scheduled meeting fromcommunication appliances associated with scheduled participants; and (d)connecting the communication appliances to communicate when theconfigured availability conditions are met.
 12. The method of claim 11wherein in step (a) a part of the configuration of a scheduled meetingis a threshold of number of scheduled participants being available toparticipate.
 13. The method of claim 11 wherein in step (b) scheduledparticipants are informed of availability of other scheduledparticipants.
 14. The method of claim 11, wherein one communicationsappliance is a mobile telephone and another communications appliance isan interactive voice response (IVR) unit.
 15. The method of claim 11,wherein one communications appliance is a personal computer and anothercommunications appliance is a web server.
 16. The method of claim 11further including a step for using geo-location of communicationsappliances relative to geo-location of an appliance associated with theuser who schedules the meeting to prioritize a list of contacts on theuser's appliance.
 17. The method of claim 11 wherein in step (c) inaddition to receiving indications of availability the server receivesindication of applications running on the communications appliancesassociated with scheduled participants.
 18. The method of claim 11wherein availability reporting is accomplished through a ping sequence.19. The method of claim 11 wherein availability reporting isaccomplished through a text channel.
 20. The method of claim 11 whereincertain expected geo-location positions and states of a party's mobilecommunications appliance are configured as conditions for availabilityof the party.